Persistence data is the licensing data that is retained on the local computer in the non-volatile storage. Licensed applications may need to refer to this data during their lifecycle under different circumstances, even beyond the expiration of a license or to manage the security of certain licensing models.

For example, persistence data ensures that a trial license cannot be re-used by your customer after it is exhausted, by such means as setting the system clock back or by uninstalling and then re-installing the application. To run the licensed application again either a new trial license or a normal license is required. Therefore, you must configure your customers’ systems to allow persistence data creation under the following scenarios.

The table below lists the destinations (systems) where persistence data is created under the listed scenarios:

Licensing Scenario	Description	Standalone System	Local System (Client)	License Manager Host
Trial in standalone licensing	To ensure that the licensed application is used as per the trial terms.		Not Applicable	Not Applicable
Trial in network licensing		Not Applicable	Not Applicable
Commuter	To ensure that the checked-out network token is usable only up to the commuter duration.	Not Applicable
Repository	To ensure that the automatically checked-out network token is usable only up to the set period.	Not Applicable
Grace	To ensure that the network token is usable only up to set grace period in the disconnected state.	Not Applicable		Not Applicable
Volume transaction in standalone licensing	To ensure that the network token is used as per the Volume Transaction Licensing terms.		Not Applicable	Not Applicable
Volume transaction in network licensing		Not Applicable	Not Applicable
Time tampering detection-enabled in standalone licensing	To ensure that any system clock tampering is detected and enforced, if allowed.		Not Applicable	Not Applicable
Time tampering detection-enabled in network licensing		Not Applicable	Not Applicable
Revocation in standalone licensing	To ensure that the revoked licenses cannot be used again.		Not Applicable	Not Applicable
Revocation in network licensing		Not Applicable	Not Applicable
Usage log in standalone licensing	To ensure usage logs are created and maintained		Not Applicable	Not Applicable
Usage log in network licensing		Not Applicable	Not Applicable
Cancel lease in standalone licensing	To ensure that the canceled lease is not obtained and used.		Not Applicable	Not Applicable
Connected (Cloud LM) mode	To check the client's authentication. Applicable only in the case of on-premises applications when the SCP-integrated library is used.	Not Applicable		Not Applicable
Sync Lease in standalone licensing	To ensure that no lease renewals are performed as long as the last-obtained lease is valid. (excluding entitlement updates)		Not Applicable	Not Applicable
Sync Lease in network licensing		Not Applicable	Not Applicable

For Standalone Scenarios

Setting up persistence data is a one-time activity and administrator rights are required. To setup the persistence data, integrate sntl_persistence_create and it's helper API functions in your application installer or create a custom utility. This API is included in the lspmgmtinit library. From Sentinel RMS 9.8 onwards, this API creates the persistence data for all the available persistence types.

For Network Scenarios

In the case of network licensing, the required persistence data is auto-created by RMS License Manager.

Starting Sentinel RMS 9.8, there is change in the persistence data for time-tamper licensing in the case of standalone system (Windows). Earlier time-tamper persistence data was specific to feature-version. That means, to use time-tamper enabled standalone license, the initialization of persistence for a particular feature-version needed to be performed.

Now, time-tamper persistence data is no longer feature-version dependent. The persistence data created once can be used for all time-tamper enabled standalone licenses.

An example:

Assume you created Sentinel RMS 9.7 based-persistence for your licensed application. To migrate, you need not invoke the sntl_persistence_create API. The migration will be automatically handled by the client application for all feature-version.

You will need to initialize the persistence data using new persistence initialization library if it is not already initialized.

The need for persistence cleaning may occur on the customers’ systems whenever they encounter persistence-related errors such as:

> SNTL_TRIAL_LIC_DATA_INCONSISTENT

>SNTL_TRIAL_LIC_NOT_ACTIVATED

>SNTL_UNABLE_TO_INSTALL_COMMUTER_CODE

>SNTL_STORE_DATA_INCONSISTENT

>SNTL_STORE_ACCESS_ERROR

These errors indicate that the corresponding persistence data is corrupted or not initialized. Hence, use of the licensed application may get interrupted. To overcome these scenarios, persistence data need to be repaired or reset. The reset operation completely removes the existing persistence information and sets it to the initial state, whereas the repairing operation fixes the corrupted data. To achieve this, the following Unified APIs are provided. Using these functions, you may also create your own persistence cleanup utilities:

APIs	Use Cases
sntl_persistence_reset	>When an end user checks out a commuter token for access beyond network, both the client and License Manager persistence are updated for that feature-version. If the client becomes permanently inaccessible (for example, the client machine gets physically damaged), the License Manager persistence needs to be cleaned to reclaim the checked out commuter token. >When an end user attempts to set the system clock back for a time tampering detection-enabled license, but fails to do. The reset needs to be performed both on the client system as well as the License Manager host.
sntl_persistence_repair	All the persistence corruption scenarios in the case of standalone and network licensing. For example, persistence corruption may take place when an end user attempts to: > Reuse an exhausted trial licenses. >Extend the availability of a grace license on the local system. If the cloud usage files are not getting generated, use of the sntl_persistence_repair API is also recommended.

NOTE   For all non-Windows, ensure that the architecture of both persistence cleaning library and RMS License Manager are same. For e.g., if you are using lserv64 (RMS License Manager), the persistence cleaning library should be lspmgmtclean64.lib and for lserv32 it should be lspmgmtclean32.lib.

For information on how to use these APIs, navigate to the Sentinel RMS SDK installation directory and refer the sample under …\Samples\C\Src\sntl_lspmgmtclean.c.